This chapter describes bridging features that are available with the Adaptive Source Routing Transparent (ASRT) bridge. The chapter includes the following sections:
The bridging tunnel (encapsulation) is another feature of the ASRT bridge software. By encapsulating packets in industry-standard TCP/IP packets, the bridging device can dynamically route these packets through large IP internetworks to the destination end-stations.
End stations see the IP path (the tunnel) as a single hop, regardless of the network complexity. This helps overcome the usual 7-hop distance limit encountered in source routing configurations. It also lets you connect source routing end-stations across non-source routing media, such as Ethernet networks.
The bridging tunnel also overcomes several limitations of regular source routing including:
With the bridge tunnel feature enabled, the software encapsulates packets in TCP/IP packets. To the device, the packet looks like a TCP/IP packet. Once a frame is encapsulated in an IP envelope, the IP forwarder is responsible for selecting the appropriate network interface based on the destination IP address. This packet can be routed dynamically through large internetworks without degradation or network size restrictions. End-stations see this path or tunnel as a single hop, regardless of the complexity of the internetwork. Figure 18 shows an example of an IP internetwork using the tunnel feature in its configuration.
Figure 18. Example of the Bridge Tunnel Feature
|
The tunnel is transparent to the end stations. The bridging devices participating in tunneling treat the IP internet as one of the bridge segments. When the packet reaches the destination interface, the TCP/IP headers are automatically removed and the inner packet proceeds as a standard source routing packet.
A major benefit of the encapsulation feature is the addition of the OSPF dynamic routing protocol to the routing process. OSPF offers the following benefits when used with encapsulation:
With OSPF, tunnels automatically manage paths inside the internetwork. If a line or bridge fails along the path, the tunnel bridge automatically reroutes traffic along a new path. If a path is restored, the tunnel automatically updates to the best path. This rerouting is completely transparent to the end-stations. For more information on OSPF, see the configuration and monitoring chapters beginning at "Using OSPF".
The IBM 2216 also supports TCP/IP Host services, which let you configure and monitor a bridge when routing functions are disabled. This option gives you the following capabilities:
When viewed from the bridge's monitoring interface, TCP/IP Host Services is handled as a new protocol having its own configuration and monitoring prompts. These prompts are accessed via the protocol command in talk 6 and talk 5.
Bridge-only management function is activated by assigning an IP address to the bridge and enabling TCP/IP Host Services (see "Configuring and Monitoring TCP/IP Host Services"). This IP address is associated with the bridge as a whole, instead of being associated with a single interface. When booting over the network, the bridge's IP address and a default gateway can be learned automatically through the ROMCOMM interface with the boot PROMs. Default gateway assignments can also be user-configured.
TCP/IP host services are available whenever bridging is an option in the device software load.
For Bridge Management via SNMP, the IBM Nways Multiprotocol Access Services supports the management information bases (MIBs) as specified by RFC 1493 and RFC 1525, except for the following MIBs:
The NetBIOS name caching feature enables the bridging device to significantly reduce the number of Name-Query frames that leave an originating ring and are forwarded through a bridge. Configuring NetBIOS name caching is part of the NetBIOS configuration. Details are in "NetBIOS Name Caching and Route Caching".
Three frame types are typically sent in groups of six:
Duplicate frame filtering uses a timer to allow only one instance of each type of frame to be forwarded through the bridge in the amount of time set by the user.
This process uses a separate database from the one used in Name Caching. Duplicate frame database entries contain the client's MAC address and three time stamps, one for each of the mentioned frame types. Duplicate-frame filtering is processed before name caching. Details are in "Duplicate Frame Filtering".
NetBIOS filtering is a feature that enables you to enhance the performance of ASRT Bridging. This feature lets you configure specific filters using the device configuration process. NetBIOS filters are sets of rules applied to NetBIOS packets to determine if the packets should be bridged (forwarded) or filtered (dropped).
There are two types of NetBIOS filtering, host name and byte:
Name filters apply to NetBIOS traffic that is being bridged or data link switched.
There are no thresholds or timers associated with these filters and they remain active until you either disable or remove them. A NetBIOS filter is made up of three parts, the actual filter, filter-lists, and filter-items (described in more detail at "Building a Filter").
Configuration and monitoring of NetBIOS is described at "Configuring and Monitoring NetBIOS". The remainder of this section describes NetBIOS host-name filtering and NetBIOS byte filtering.
NetBIOS filtering using host names lets you select packets with specific NetBIOS host names to be bridged or filtered. When you specify that packets with a particular NetBIOS host name (or set of NetBIOS host names) should be bridged or filtered, the source name or destination name fields of the following NetBIOS packet types are examined:
The host-name filter-lists specify NetBIOS names that should be compared with source or destination name fields in the four different types of NetBIOS packets. The result of applying a host-name filter-list to a NetBIOS packet that is not one of those four types is Inclusive.
When configuring NetBIOS Filtering using host names, you specify which ports the filter is applied to and whether it is applied to input or output packets on those ports. Only NetBIOS Unnumbered Information (UI) packets are considered for filtering. Filtering is applied to NetBIOS packets that arrive at the device for either source route bridging (all RIF types) or transparent bridging.
When specifying a NetBIOS host name in a filter, you can indicate the 16th (last) character of the name, as a separate argument, in its hexadecimal form. If you do this, the first 15 bytes of the name are taken as specified and the 16th byte (if any is specified) is determined by the final argument. If you specify fewer than 16 characters (and no 16th byte), then the name is padded with ASCII blank characters up to the 15th character and the 16th character is treated as a wildcard.
When a specific NetBIOS host name is evaluated, that name is compared with only certain fields of certain NetBIOS packets. NetBIOS host names in filter items may include a wildcard character (?) at any point in the NetBIOS host name, or an asterisk (*) as the final character of a NetBIOS host name. The ? matches against any single character of a host name. The * matches against any one or more characters at the end of a host name.
Another filtering mechanism, byte filtering, lets you specify which NetBIOS packets should be bridged or filtered based on fields in the NetBIOS packets that relate to the MAC address. In this case, all NetBIOS packets are examined to determine if they match the configured filtering criteria.
To build a byte filter, you specify the following filter-items:
The length of the mask, if present, must be of equal length to the byte pattern. The mask specifies bytes that are to be logically ANDed with the bytes in the NetBIOS header before the device compares the header bytes with the hex pattern for equality. If no mask is specified, it is assumed to be all ones. The maximum length for the hex pattern (and hence the mask) is 16 bytes (32 hexadecimal digits).
When configuring NetBIOS filtering using specific bytes, you also specify which ports the filter is applied to and whether it is applied to input or output packets on those ports.
Each filter is made up of one or more filter-lists. Each filter-list is made up of one or more filter-items. Each filter-item is evaluated against a packet in the order in which the filter-item was specified.
When a match is found between a filter-item and a packet, the device:
If no filter-items in the filter-list produce a match, the device:
A filter-item is a single rule applied to a particular field of a NetBIOS packet. The result of the application of the rule is either an Inclusive (bridge) or an Exclusive (filter) indication. The following filter-items can be configured with NetBIOS filtering (the first two items are host-name filters, the last two items are byte filters):
Part of the specification of a filter indicates whether packets that do not match any of the filter-items in the filter-list should be bridged (included) or filtered (excluded). This is the default action for the filter-list. The default action for a filter-list is initially set to Include, but this setting can be changed by the user.
A simple filter is constructed by combining one filter-list with a device port number and an input/output designation. This indicates that the filter list should be applied to all NetBIOS packets being received or transmitted on the given port. If the filter-list evaluates to Inclusive, then the packet being considered is bridged. Otherwise, the packet is filtered.
A complex filter can be constructed by specifying a port number, an input/output designation, and multiple filter-lists separated by one of the logical operators AND or OR. The filter-lists in a complex filter are evaluated strictly left to right, and each filter-list in the complex filter is evaluated. Each inclusive filter-list result is treated as a true and each exclusive filter-list result is treated as a false. The result of applying all the filter-lists and their operators to a packet is a true or false, indicating that the packet is bridged or filtered. Each combination of input/port or output/port can have at most one filter.
The ASRT bridge lets you extend spanning tree protocol options to cover as many configuration options as possible. The following sections provide information on these features.
Bridging technology employs different versions of spanning tree algorithms to support different bridging methods. The common purpose of each algorithm is to produce a loop-free topology.
In the spanning tree algorithm used by transparent bridges (TBs), Hello BPDUs and Topology Change Notification (TCN) BPDUs are sent in a transparent frame to well known group addresses of all participating media (Token-Ring, Ethernet, FDDI, and so on). Tables are built from this exchanged information and a loop-free topology is calculated.
Source routing bridges (SRBs) transmit spanning tree explorer (STE) frames across other SRBs to determine a loop-free topology. The algorithm sends Hello BPDUs in a transparent frame to well known functional addresses. Since TCN BDPUs are not used by SRBs, the port state setting created as a result of this spanning tree algorithm does not affect all route explorer (ARE) frame and specifically routed frame (SRF) traffic.
In bridging configurations using IBM 8209 Bridges, a different spanning tree method is used to detect parallel IBM 8209 bridges. This algorithm uses Hello BPDUs sent as STE frames to IEEE 802.1d group addresses on the token ring. On the Ethernet, Hello BPDUs sent as transparent frames to the same group address are used. This method enables 8209s to build spanning trees with transparent bridges and other IBM 8209 bridges. It does not participate in the SRB spanning tree protocol, however, and Hello BPDUs sent by SRBs are filtered. Consequently, there is no way to prevent the 8209 from becoming the root bridge. If the 8209 bridge is selected as the root, then traffic between two transparent bridge domains may have to pass through token-ring/SRB domains.
As you can see, running multiple spanning tree protocols can cause compatibility problems with the way algorithm creates its own loop-free topology.
The STP/8209 bridging feature is available to enable you to further extend the Spanning Tree protocol. Previously, SRBs allowed only manual configuration of a loop-free tree over the token-ring. This was the only mechanism to prevent loops in the case of parallel SR-TB bridges. With the addition of the STP/8209 feature the following spanning tree algorithm combinations are possible:
Threading is a process used by a token-ring end station protocol (for example, IP, IPX, or AppleTalk) to discover a route to another end station through a source-routing bridged network.
The details of the threading process vary according to the end station protocol. The following sections describe the threading process for IP, IPX, and AppleTalk.
IP end-stations use ARP REQUEST and REPLY packets to discover a RIF. Both IP end-stations and the bridges participate in the route discovery and forwarding process. The following steps describe the IP threading process.
As the ARP REQUEST packet continues its search for the destination end-station, each bridge that forwards it adds its own bridge number and segment number to the RIF in the packet. As the frame continues to pass through the bridged network, the RIF compiles a list of bridge and segment number pairs describing the path to the destination.
When the ARP REQUEST packet finally reaches its destination, it contains the exact sequence of bridge and segment numbers from source to destination.
IPX end-stations check each packet they receive for a RIF. If the RIF does not exist in the table, they add the RIF to the table and designate that route as HAVE_ROUTE. If the RIF indicates that the packet came from an end-station on the local ring, the route is designated as ON_RING.
If the end-station needs to send out a packet and there is no entry in the RIF table for the MAC address, the end-station transmits the data as an STE.
When the RIF timer expires, the entry in the table is cleared and will not be reentered until another packet arrives containing a RIF for that entry.
AppleTalk end-stations use ARP and XID packets to discover a route. Both the AppleTalk end-stations and the bridges participate in the route discovery process and forwarding. The following steps describe the AppleTalk threading process.
The duplicate MAC address (DMAC) feature enables you to attach an SR-TB bridge to a SR bridged network that has duplicate MAC addresses configured. The duplicate MAC address feature can be enabled with two options:
This option enables you to enable duplicate MAC addresses without load-balancing. In this case, only one RIF is learned for the duplicate MAC address and aging is performed on this learned RIF. All stations from the TB domain will use this one RIF to communicate with that MAC address. When the entry for this RIF ages out, the next frame will be sent from the TB domain as a Spanning Tree Explorer (STE) frame.
This option enables you to enable duplicate MAC addresses with load-balancing and can be enabled only after enabling DMAC without Load-Balance. In this case, two RIFs are learned and maintained for each duplicate MAC address. Each of the two RIFs will have its own aging timer. Whenever the bridge receives a frame with a particular RIF, the aging value corresponding to that RIF will be refreshed. The first time a station from the TB domain sends a frame to a duplicate MAC address, the bridge software decides which RIF will be used to send that frame. All subsequent frames from the sending station will be sent using that same RIF. The bridge will maintain primary and secondary RIFs for up to seven duplicate MAC addresses. If you specify separate age values for duplicate MAC addresses, the appropriate value will be used to age out entries corresponding to that duplicate MAC address, enabling you to tune the aging value for duplicate MAC addresses.
The device supports bridging over native ATM (RFC 1483). When bridging over native ATM, multiple (virtual) ports may be configured for a single (physical) interface.
RFC 1483 specifies an LLC value of 0xAA-AA-03 and an OUI value of 0x00-80-C2 for bridged protocols. The 2-octet PID portion of the SNAP header, in the case of bridged protocols, specifies the bridged media, and additionally, whether the original frame check sequence (FCS) is preserved within the original bridged PDU. The PID values for the different media are specified. Refer to RFC 1483 for further details.
The ATM interface will forward bridged MAC frames to and from Token Ring/802.5, Ethernet/802.3 and FDDI. One bridge port is used per VCC. While configuring a bridge port on an ATM interface, you must specify a VCC that is permanently tied to that port. Bridged frames received on a port/VCC are sent out on one or more ports/VCCs as per the bridging protocol being used and the bridging configuration. Once a bridge port is configured on an ATM interface and has a VCC associated with it, it functions as a normal bridging port on a legacy LAN. The association of the port with an ATM interface is transparent to the user and to the bridging function.
When configuring a bridge port on an ATM interface, the user must specify whether PVC or SVC support should be used. For PVC support, you must provide the VPI and VCI for the PVC. For SVC support, you must provide the remote ATM address as well as the selector to be used for the local address.
| Note: | Unlike PVC support, using SVCs does not require any configuration at the intermediate switches. |
Once a port has been added on an ATM interface, the bridging configuration commands that require a port number as a parameter can be used with this port number.
Refer to "Using ARP" and "Configuring and Monitoring Bridging" for additional information on configuring bridging over ATM.
A multiaccess bridge port is a bridge port that includes all Frame Relay virtual circuits that are not individually configured as bridge ports. The multiaccess bridge port is assigned a unique bridge segment number, which is used for source routing bridging.
A multiaccess bridge port has the following bridging characteristics:
| Note: | This is the preferred configuration because Spanning Tree protocol can consume considerable WAN bandwidth and most configurations are not fully meshed. |
Each multiaccess bridge port maintains a multiaccess database that maps the next-hop segment number to the Frame Relay virtual circuit on which the frame was received. Database entries are built or updated as the segment receives ARE, STE, or specifically routed frames from the circuits. STE and ARE frames that are to be forwarded onto the multiaccess segment are flooded to all virtual circuits in the multiaccess segment. Specifically routed frames that are to be forwarded onto the multiaccess segment are only forwarded if there is a multiaccess database entry that maps the next-hop segment number to a virtual circuit.
The software "ages out" entries in the multiaccess database at a rate that you specify with the multiaccess-age command.
The following example illustrates how to configure multiaccess bridge ports on Frame Relay interfaces 1 and 4. Port 5 is the next available bridge port and this is the first time source routing is being enabled.
* talk 6 Config> prot asrt ASRT Config> add multiaccess-port ASRT Config> Interface number [0]? 1 ASRT Config> Port Number [5]? ASRT Config> Segment Number for the port in hex (1 - FFF) [001]? 300 ASRT Config> Bridge Number in hex (0 - 9, A - F) [0]? 2 ASRT Config> Bridge Virtual Segment Number (1 - FFF) [001]? CCD ASRT Config> add multiaccess-port ASRT Config> Interface number [0]? 4 ASRT Config> Port Number [6]? ASRT Config> Segment Number for the port in hex (1 - FFF) [001]? 400
| Note: | You are not prompted for bridge number and virtual segment number after configuring the first multiaccess bridge port. |
Using multiaccess ports with 2210/2212/2216 devices as data catchers can provide a high density, high availability topology for the 2218s in your network.
For the 2218 to switch between the primary and central bridges without losing LLC connections between itself and the central bridge you must:
| Note: | This configuration only supports branch-to-datacenter connectivity. |
Figure 19 shows a typical network connection between 2216s and 2218s.
Figure 19. Sample Configuration with 2218 and Multiaccess Bridge Ports
 |